Logically, a window system cursor ``floats'' above the windows on the screen. Standard dumb frame buffer graphics hardware for window systems requires special software support for managing the window system cursor.
The standard ``software cursor'' technique [13] used to manage the window system cursor is to save the pixels under the cursor when the cursor is rendered. When the cursor's image might interfere with rendering or frame buffer read back, the cursor must be undrawn (restoring the saved pixels) and redrawn on completion of the rendering or read back.
The undraw/redraw technique described above is reasonable if the window system server is the only renderer and the window system server manages the cursor. But using direct rendering, asynchronous direct renderers need to render into windows containing the cursor but do not have immediate knowledge of the cursor to utilize the undraw/redraw technique. Techniques for integrating software cursors with direct rendering have been implemented [2], but they require a graphics hardware locking strategy that is incompatible with SGI's goal of ``maximum performance'' rendering.
The alternative to a software cursor is hardware support for a cursor. Normally, this consists of support in the video back end that merges in the cursor image into the video output. Using a hardware cursor eliminates both the rendering overhead and flicker of the software technique. All SGI graphics hardware supports hardware cursors, thereby decoupling direct renderering from window system cursor management.